home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000042_icon-group-sender _Sun Jan 24 02:09:19 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
3KB
Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 05:57:30 MST
Date: Sun, 24 Jan 93 02:09:19 MST
From: whm@shepard.sunquest.com (Bill Mitchell)
Message-Id: <9301240909.AA02066@shepard.sunquest.com>
To: icon-group@cs.arizona.edu
Subject: Re: builtin Icon functions
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
From: gmt@cs.arizona.edu("Gregg Townsend")
Date: Sat, 23 Jan 93 11:54:17 MST
Subject: builtin Icon functions
I am amused by postings that state "I never use X, so I suggest that X
should be removed from the library". That's an awfully self-centered
view. While I never use acos() or bal(), that doesn't mean that I think
they should be deleted.
Well, I think you need to read between the lines on such statements. I think
that what's usually meant is that "I never use it and I think most persons
don't use it."
A defensible criterion is the one states "If it can be programmed
in Icon, it belongs in the IPL instead of being a builtin function".
...
But (as you know) if follow that far enough, you're left with only
enough of a language to simulate a Turing machine!
My own opinion is that a large repertoire of preprogrammed operations
greatly increases the utility of a language, whether these are supplied
as operators or builtin functions. Certainly FORTRAN would not have
succeeded without its math library. Accordingly, I support the inclusion
of tab(), bal(), sin(), detab(), and other functions, and would like to
see more.
I think a too large repertoire *decreases* the utility of the language. My
canonical example: The set of functions that come with GNU Emacs Lisp.
It's too much to remember and too much to read! Every additional feature
adds a little weight. A little more work to implement, a little more work
to document, a little more documentation to read, a little more to
remember.
I that the challenge in designing programming facilities is to provide a
concise set of facilities that provides good coverage of the problems in
the perceived domain of the language. If the set's too small, all the users
end up reinventing the wheel. If too big, well, see above.
Ralph once told me (c. 1982) that if I wanted to add a feature to Icon, I'd
have find a feature to throw out. A few features have been added since then
and mostly to the good of the language, but as a rule to put on the wall,
I think it's a pretty good one.